This is surprisingly simple! Some high-level comments; leaving naming out of the picture for now:

Introduces ConstraintFactory.staticData(Uni), which creates an independent NodeNetwork from the provided Uni stream.

I'm not a big fan of this. The programming model doesn't look very nice IMO.

factory.staticData(factory.forEach()...)
    .filter(...)

Something like this would be more stream-y:

factory.forEach().
    ...
    .asStatic()
    .filter(...)

This brings its own problems. But both proposals share the same issue - chaining static streams. Nothing (other than run-time fail-fasts) prevents you from doing staticData(staticData(...).filter(...)). IMO we should decide (and enforce) that a static stream can only be built once, and everything after that is dynamic. And ideally, this would happen at type level, not at runtime.

This was the main idea of filterStatic() - because we can actually guarantee, at type level, that once any "non-static" method is called, a "static" method can never be called again. (The reverse doesn't work, unless we want to duplicate the entire stream API, which we don't.) IMO we shouldn't rule out filterStatic() + joinStatic() - under the hood, it can be implemented like in this PR, but the public API IMO need not offer this absolute flexibility to turn anything into static data.

To bring an alternative API idea:

 factory.forEachXYZ(Something.class, filter)

This would produce a StaticUniStream which extends UniStream, and only adds one method - joinXYZ(); this join only allows to join other static streams and returns StaticBiStream - allowing possibly for a static bi join (and similarly for tri).

In essence, this brings a very simple, clear API:

• We support static filters and joins (maybe also ifExists, which is essentially a join).
• Static operations come first.
• Once you go dynamic, you can never go back.
• This is enforced at the type level, preventing impossible situations from being modelled.
• Node-sharing is trivial; nothing changes in the status quo.

It does have a downside - it doesn't allow arbitrary static streams, such as groupBy, map, flatten etc. Right now, nobody is asking for it, and I think it is a decent trade-off to get the benefits; but we can possibly ask other people for their opinion on this.

Good progress! What do you still need to do here?

Implementation should be done; need more tests and a finalized design.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
71.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud